AI/ML数据基础设施参考架构
引言
在企业级AI领域，判别式（discriminative）和生成式（generative）是两种主要模型类型。判别式模型用于数据的分类和预测，而生成式模型则负责创建新数据。尽管近期生成式AI备受瞩目，但许多企业仍在同时追求这两种AI类型。对于那些追求高效运营和额外收入的企业而言，判别式AI依然具有重要意义。尽管这些AI类型有诸多相似之处，但在构建AI数据基础设施时，仍需充分考虑它们之间的关键差异。
企业不应仅为AI设立专门的基础设施，而忽视商业智能、数据分析和数据科学等其它工作负载。应构建一个全面的数据基础设施，以满足企业所有需求，包括商业智能、数据分析、数据科学、判别式AI和生成式AI。
现代化数据湖
现代化数据湖结合了数据仓库和数据湖的特点，并利用对象存储来管理所有数据。对于数据湖而言，使用对象存储非常合适，因为它特别适合存储非结构化数据，这也是数据湖的主要存储目标。尽管对于数据仓库来说，使用对象存储可能显得不太常规，但这种新型构建方式正代表着数据仓库的下一代发展趋势。这得益于由Netflix、Uber和Databricks共同开发的开放表格格式（OTF，Open Table Format）规范，这些规范使得在数据仓库中使用对象存储变得简单高效。
OTF包括Apache Iceberg、Apache Hudi和Delta Lake，它们分别由Netflix、Uber和Databricks开发，以满足当时市场上无法满足的数据需求。这些规范以不同方式定义了可以构建在对象存储上的数据仓库。对象存储提供了其它存储解决方案无法比拟的可扩展容量和高性能组合。作为现代化规范，它们还具备传统数据仓库所没有的高级功能，如分区演化（partition evolution）、模式演化（schema evolution,）和零拷贝分支（zero-copy branching）。此外，由于数据仓库建立在对象存储之上，还可以使用相同的对象存储来管理图像、视频文件、音频文件和文档等非结构化数据，这些数据通常存储在所谓的数据湖中。因此，使用对象存储作为数据湖和数据仓库的基础，可以构建一个能够容纳所有数据的解决方案，其中结构化数据存储在基于OTF的数据仓库中，而非结构化数据则存储在数据湖中。
我们将基于OTF的数据仓库与数据湖的组合称为现代化数据湖，并将其视为所有AI/ML工作负载的基础。这里是数据收集、存储、处理和转换的中心。使用判别式AI（包括监督学习、无监督学习和强化学习）进行模型训练时，通常需要能够处理结构化数据的存储解决方案，这些数据可以存储在数据仓库中。而如果正在训练大型语言模型（LLM），则必须在数据湖中管理非结构化数据或文档的原始和处理形式。
本文重点介绍了现代化数据湖参考架构中与AI/ML工作负载相关的关键领域。这些功能区域包括：
判别式AI（Discriminative AI）
非结构化数据存储
半结构化数据存储
数据仓库中的零拷贝分支
生成式AI（Generative AI）
使用向量数据库构建自定义语料库
构建文档处理管道
检索增强生成（RAG）
对LLM进行微调
评估LLM的准确性
ML运营
GPU现状分析
解析GPU资源短缺问题
探讨如何提升对象存储性能
两家企业的AI基础设施建设实例 打造高效AI数据基础设施的策略规划
判别式AI
判别式AI模型在训练过程中需要用到多种类型的数据。比如，用于图像分类和语音识别的模型会利用图像和音频文件等非结构化数据。而用于欺诈检测和医疗诊断的模型则依赖于结构化数据进行预测。接下来，我们将探讨现代化数据湖中存储和处理判别式AI所需数据的方案。
非结构化数据存储方案
非结构化数据主要存储在数据湖中，用于模型的训练和测试。在训练开始前，可以将适合内存的训练集加载至内存中（即在训练周期开始之前）。然而，当训练集规模庞大到无法完全载入内存时，就需要在训练前加载对象列表，并在每个训练批次处理时实时检索对应的数据对象。若数据湖未配备高速网络和高速磁盘驱动器，可能会给数据湖带来压力。因此，若正在使用大规模数据训练模型，建议采用100Gb高速网络和NVMe SSD来构建和优化数据湖。
半结构化数据存储方案
现代化数据湖提供了多种方案来存储半结构化文件，如Parquet文件、AVRO文件、JSON文件，甚至CSV文件。最简单的方式是将这些文件直接存储在数据湖中，并以与非结构化数据相同的加载方式进行加载。若这些半结构化文件中的数据无需被数据湖中的其它工作负载（如商业智能、数据分析和数据科学）使用，那么这种方法最为合适。
另一种选择是将这些文件加载到数据仓库中，以便其它工作负载也能使用这些数据。当数据加载到数据仓库后，可以利用零拷贝分支功能对数据进行实验和分析。
数据仓库中的零拷贝分支
特征工程是一种用于改进用于训练模型的数据集的技术。基于OTF的数据仓库拥有一个非常巧妙的特性，即零拷贝分支。这允许数据像在Git仓库中可以分支代码一样进行分支。顾名思义，零拷贝分支并不实际复制数据，而是借助数据仓库所使用的开放表格式的元数据层，创造出数据唯一副本的假象。
数据科学家可以在这些分支上进行各种实验。如果实验取得了成功，他们可以将该分支合并回主分支，供其他数据科学家使用。若实验未能达到预期效果，则可以选择删除该分支。
生成式AI
无论是使用Scikit-Learn构建的小型模型，还是基于PyTorch或TensorFlow构建的复杂神经网络，亦或是基于Transformer架构的LLM，它们都需要数字作为输入，并产生数字作为输出。这一基本事实对AI/ML基础设施提出了更高的要求，特别是对于那些关注生成式AI的企业，因为在这个过程中，需要将单词转化为数字（或向量）。若希望使用包含公司专有知识的私有文档来优化LLM生成的答案，生成式AI解决方案将变得更加复杂。这种优化可能包括RAG或LLM微调等形式。
本章节将解读上述技术（单词到数字的转换、RAG和微调）及其对AI基础设施的影响。首先，我们将从如何构建自定义语料库及其存放位置开始探讨。
使用向量数据库构建自定义语料库
若对生成式AI有着较高的期望，那么自定义语料库将是企业独特性的体现。它应包含那些其它人所不具备的专有知识文档，并且这些文档应确保真实准确。此外，建议使用向量数据库来构建自定义语料库。向量数据库能够索引、存储并提供对文档及其向量嵌入的访问，这些向量嵌入是文档的数字表示，从而解决了上述数字转换问题。
向量数据库能够支持语义搜索。虽然其背后的数学原理较为复杂，但从概念上理解语义搜索却相对简单。例如，假设想要查找所有与“artificial intelligence”相关的文档。若在传统数据库上执行此操作，需要搜索“artificial intelligence”的所有可能缩写、同义词和相关术语，你的查询可能会看起来像这样：
SELECT snippetFROM MyCorpusTableWHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...手动执行相似性搜索不仅繁琐且容易出错，而且搜索本身也非常缓慢。而向量数据库则能够接收类似的查询请求，并以更高的速度和准确性返回结果。因此，若计划使用RAG技术，能够快速准确地执行语义查询将至关重要。
{Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} }}自定义语料库的安全性至关重要。在访问文档时，必须严格遵守原始文档所设定的访问限制。试想，如果实习生能够接触到尚未向华尔街公开的CFO财务结果，这无疑是个巨大的隐患。因此，在向量数据库中，务必设置恰当的权限，确保文档的访问级别与原始内容保持一致。这通常可以通过将向量数据库与企业的身份和访问管理解决方案进行集成来实现。
核心在于，向量数据库主要存储非结构化数据，因此，它应当依托数据湖作为存储解决方案。
构建文档管道
遗憾的是，许多企业并没有一个集中且内容准确、格式统一的文档存储库。相反，文档常常以各种格式分散在企业内部各个团队的门户中。因此，构建自定义语料库的首要任务便是搭建一个管道，专门用于抓取那些已获准用于生成式AI的文档，并将其导入到向量数据库中。对于大型跨国企业而言，这往往是生成式AI解决方案中最为艰巨的任务。因为在这些企业中，团队门户中往往存放着大量处于草稿状态的文档，甚至可能包含一些随意记录的想法和可能性。这些文档不应成为自定义语料库的一部分，因为它们无法准确反映企业的业务情况。遗憾的是，筛选这些文档往往需要人工操作。
此外，文档管道还需将文档转换为文本格式。幸运的是，目前已有多个开源库支持多种常见文档格式的文本转换。同时，在将文档保存到向量数据库之前，文档管道还需将文档分割成若干小段。这是因为当这些文档用于RAG时，会受到提示大小的限制，这一点将在后续章节中详细讨论。
对大型语言模型进行微调
微调LLM的过程，实质上是利用自定义语料库中的信息对模型进行轻度训练。这通常是获取特定领域LLM的有效途径。尽管微调确实需要一定的计算资源，但与从头开始训练模型相比，其资源需求相对较小，且能在较短的时间内完成。
如果业务领域包含一些不常见的专业术语，那么微调可能有助于提高LLM输出的质量。例如，涉及医学研究、环境研究或与自然科学相关的项目，可能会从微调中提升价值。微调能够将文档中高度特定的术语融入模型的参数中。然而，在决定采用微调方法之前，我们需要充分了解其优缺点。
缺点： 微调需要消耗计算资源 微调过程往往缺乏可解释性 为了保持语料库的时效性，需要定期使用新数据重新进行微调 微调后的模型可能会产生“幻觉”问题 在微调过程中，无法实现文档级别的安全性控制 优点： 通过微调，LLM能够获取自定义语料库中的知识 与RAG相比，微调后的模型推理流程更为简洁
对LLM进行微调虽然是一种教会其理解公司业务语言的好方法，但它也会稀释数据。因为大多数LLM都包含数十亿个参数，而数据将分散在这些参数中。微调最大的问题在于无法实现文档级别的授权控制。一旦文档用于微调，其信息就会成为模型的一部分，无法再根据用户的授权级别来限制这些信息的访问。
接下来，我们将探讨一种在推断过程中结合自定义数据和参数数据的技术。
检索增强生成（RAG）
RAG是一种创新技术，它从用户提出的问题出发，利用向量数据库将问题与外部数据相联系，进而将问题连同相关数据传递给LLM进行内容生成。在RAG中，我们无需进行模型训练，而是通过向LLM发送来自我们优质文档语料库的相关文本片段来指导其生成内容。
以问答任务为例，RAG的工作流程如下：用户在应用程序的用户界面提出问题，应用程序捕获该问题中的关键词，并借助向量数据库在优质文档语料库中搜索与之相关的上下文文本片段。随后，这些片段连同原始问题被发送给LLM。这个由问题加上相关片段（即上下文）组成的整体被称为“提示”。LLM将利用这些信息生成答案。这看似简单，但如果已经知道答案（片段），为何还要使用LLM呢？关键在于，这是实时进行的，目标是生成新的文本内容，可以直接用于研究等场景。我们需要LLM来创建融合了我们自定义语料库信息的文本。
缺点： 推理流程更为复杂 优点： LLM直接从自定义语料库获取知识 可解释性高 无需微调 幻觉现象明显减少，并可通过检查向量数据库查询结果进行有效控制 可实现授权控制
ML运营（MLOps）
为了更好地理解MLOps的重要性，我们可以将其与传统应用程序开发进行对比。在开发新微服务或为应用程序添加新功能时，传统开发流程通常从审查规范开始，涉及设计新的数据结构或对现有结构进行变更。一旦编码开始，数据结构的设计便不应再变动。随后是服务的实现，其中编码是核心环节。此外，还需编写单元测试和端到端测试，以验证代码的正确性和规范实现的准确性。这些测试可在整个应用程序部署前由CI/CD管道自动执行。
然而，模型创建与训练的过程截然不同。它始于对原始数据和预测目标的深入理解。尽管ML工程师需要编写一些代码来构建神经网络或设置算法，但编码并非主要活动，实验才是重中之重。在实验过程中，数据设计、模型设计以及所用参数都可能发生变化。每次实验后，都会生成反映模型训练表现的指标，以及模型在验证集和测试集上的性能指标。这些指标用于证明模型的质量。一旦模型准备就绪并集成到应用程序中，还需进行打包和部署。
MLOps，即机器学习运营，是一组旨在解决上述差异的实践和工具。虽然实验跟踪和协作是与MLOps最为相关的功能，但现代化MLOps工具所能做的远不止于此。例如，它们可以为实验提供运行时环境，并在模型准备好集成到应用程序时负责其打包和部署。以下是现代化MLOps工具所具备的功能概览，同时还包括其它需要考虑的因素，如技术支持和数据集成。
主要参与者支持：MLOps技术和功能不断演进，因此需要选择一个由业界主要参与者支持的工具，以确保其持续发展和改进。 现代化数据湖集成：实验会产生大量结构化和非结构化数据。理想情况下，这些数据应存储在数据仓库和数据湖中。然而，由于许多MLOps工具在现代化数据湖的开放表格格式出现之前就已存在，因此大多数工具对于结构化数据都有独立的解决方案。 实验跟踪：记录每个实验的数据集、模型、超参数和性能指标，并促进实验的可重复性。 促进协作：允许团队成员查看所有ML工程师运行的所有实验的结果。 模型打包：使模型能够从其它编程环境中被访问和使用。 模型服务：将模型部署到企业的生产环境中。如果企业已经建立了将模型纳入现有CI/CD管道的方法，则可能不需要此功能。 模型注册表：维护所有模型的所有版本信息。 无服务器函数：部分工具提供了允许将代码注释为容器化服务的功能，以便在集群中运行实验或部署函数和模型。 数据管道功能：一些MLOps工具旨在提供完整的端到端功能，包括构建用于检索和存储原始数据的管道。如果企业已拥有数据管道，则可能不需要此功能。 训练管道功能：能够编排无服务器函数以形成有向无环图，并允许计划和运行训练管道。
GPU对AI数据基础设施的影响
在AI/ML基础设施中，速度往往取决于最薄弱的环节。如果使用GPU进行ML模型训练，那么存储解决方案可能成为瓶颈。这会导致所谓的“饥饿GPU问题”（Starving GPU Problem），即当网络或存储解决方案无法快速提供训练数据给训练逻辑时，GPU的性能无法得到充分利用。如果监测GPU，会发现它们远未达到满负荷运行。而一旦对训练代码进行性能分析，会发现总的训练时间主要被IO操作占据。
不幸的是，对于正面临这一挑战的人来说，有个坏消息。GPU的速度正在不断提升。从GPU的现状以及相关的技术进展来看，未来几年这个问题可能会愈发严重。
GPU的现状
GPU的速度日益加快，不仅体现在原始性能上，其内存和带宽也在不断提升。以Nvidia最新的A100、H100和H200 GPU为例，我们可以明显看到这一趋势。
A100：性能 624TFLOPS， 内存 40GB，内存带宽 1,555GB/s
H100：性能 1979TFLOPS， 内存 80GB，内存带宽 3.35TB/s
H200：性能 1979TFLOPS， 内存 141GB，内存带宽 4.8TB/s
从上述数据中，我们可以观察到几点。首先，H100和H200的性能相同，均为1979TFLOPS，是A100的3.17倍。H100的内存是A100的两倍，内存带宽也有相应的提升，这是合理的，否则GPU将因数据供应不足而无法充分发挥性能。H200更是能处理高达141GB的内存，并且其内存带宽也与其它GPU成比例地增加。
接下来，我们进一步分析这些统计数据，并探讨它们对ML的意义。
性能：TFLOP代表每秒进行一万亿次浮点运算。这是一个庞大的数字，后面跟着12个零。将TFLOP与IO需求中的GB进行直接比较是困难的，因为模型训练中的浮点运算涉及复杂的张量数学以及对损失函数（即梯度）的一阶导数计算。然而，我们可以进行相对比较。从上述统计数据可以看出，H100和H200的性能都是1979TFLOPS，速度提升了三倍。如果其它所有条件都保持不变，那么它们处理数据的速度也可能提升三倍。
GPU内存：也称为视频RAM或图形RAM。GPU内存与系统主内存RAM是分开的，专门用于处理图形卡执行的密集图形处理任务。在训练模型时，GPU内存决定了批处理的大小。过去，当训练逻辑从CPU转移到GPU时，批处理大小通常会减小。但随着GPU内存在容量上逐渐接近甚至超过CPU内存，用于GPU训练的批处理大小将会逐渐增大。当性能和内存容量同时提升时，结果就是每个请求处理的数据量更大，且处理速度更快。
内存带宽：可以将GPU内存带宽视为连接内存和计算核心的“高速公路”，它决定了每单位时间内可以传输的数据量。就像更宽的高速公路允许更多的车辆在给定时间内通过一样，更高的内存带宽允许更多的数据在内存和GPU之间传输。正如所见，这些GPU的设计者根据内存的增加，相应地提升了每个新版本的内存带宽，以确保芯片的内部数据总线不会成为瓶颈。
为模型训练加速对象存储
如果遇到了“饥饿GPU问题”，那么考虑使用100Gb网络和NVMe SSD可能是一个解决方案。最近进行的基准测试表明，通过配置这样的网络和设备，仅使用32个NVMe SSD节点就能实现325GiB/s的GET速度和165GiB/s的PUT速度。
随着计算技术的不断发展和DRAM价格的下降，我们发现服务器配置通常配备了500GB或更多的DRAM。在处理大规模部署时，即使是超高密度的NVMe SSD，每个实例的服务器数量乘以这些服务器上的DRAM也会迅速累积，通常是每个实例的许多TB。
这个DRAM池可以配置为分布式共享内存池，非常适合处理需要高IOPS和吞吐量性能的工作负载。因此，我们构建了缓存机制，使我们的企业和企业Lite客户能够配置其基础设施，以利用这个共享内存池，从而进一步提高核心AI工作负载的性能，如GPU训练，同时保持数据的持久性。
两个企业案例
为了深入了解AI/ML的应用与实践，让我们以两个企业为例，它们在AI/ML之旅中采取了截然不同的方法。
企业1秉持“迭代改进”的理念。他们认为，任何大型计划都可以被拆解成更小、更易于管理的项目。这些项目依次进行，每个项目都基于前一个项目的成果，逐步解决更为复杂的问题。企业1更偏爱这种小型项目的方式，因为每个项目都能为业务带来实实在在的价值。他们发现，那些仅涉及基础设施升级或软件现代化、没有新增功能的项目，在预算控制严格的高管眼中并不受欢迎。因此，他们意识到，为生成式AI的概念验证请求大量的存储设备和计算集群，并不是优化基础设施与软件功能结合的最佳方式。相反，他们更倾向于选择能够随着业务增长而扩展的基础设施产品，并从简单的AI模型开始，以便更好地整合MLOps工具，并与现有的DevOps团队和CI/CD管道协同工作。
而企业2则奉行“追求新奇”的文化。每当行业涌现出新的技术，他们总是迫不及待地挑战最高难度的项目，以展示其技术实力。这些项目在内部和外部都引起了极大的关注。在他们看来，任何问题都有聪明人来解决。
企业1选择从在主要电子商务网站上建立推荐模型开始其AI/ML之旅。推荐模型相对简单，易于训练，仅使用了文件共享中已有的数据集。虽然项目规模不大，但团队却借此机会建立了一个小型但可扩展的现代化数据湖，引入了MLOps工具，并积累了一些关于模型训练和部署的最佳实践。尽管模型本身并不复杂，但它为网站带来了显著的效率提升。企业1凭借这些积极的成果，为下一个生成式AI项目争取到了资金。
企业2则决定为其电子商务网站打造一个聊天机器人，用于回答客户关于产品的问题。LLM较为复杂，而团队对此类技术的细节如微调或RAG并不熟悉。因此，项目周期主要集中在快速学习新技术上。最终，聊天机器人虽然达到了可接受的效果，但并无太多亮点。由于缺乏MLOps工具的支持，机器人需要手动加载到预生产和生产环境中，这导致了与DevOps团队之间的摩擦。此外，机器人在生产环境中还出现了稳定性问题，支撑其运行的集群计算能力不足以应对生成式AI的工作负载。在高峰期，机器人甚至出现了故障，迫使团队紧急增强集群性能。项目结束后，企业2意识到，要想在AI领域取得成功，必须加强基础设施建设。
构建AI/ML数据基础设施计划
上述两个案例虽然极端，但为我们提供了宝贵的启示。构建AI模型（无论是判别式还是生成式）与传统软件开发有着本质的区别。因此，在规划AI/ML工作时，我们必须充分考虑这一点。下面是对这两个案例的总结，展示了“AI数据基础设施优先”与“模型优先”两种方法的对比。正如案例所示，基础设施优先并不意味着每个组件都必须作为独立项目来实施。企业应积极探索在构建基础设施的同时实现AI交付的创新方法，这可以通过从简单项目入手，逐步挑战更复杂的AI任务来实现。
打造高效数据湖 利用OTF构建完善数据仓库 部署MLOps工具链 推行MLOps最佳实践 搭建分布式训练集群 训练判别式AI模型 训练生成式AI模型
优先训练生成式AI模型 随后训练判别式AI模型 搭建分布式训练集群 推行MLOps最佳实践 部署MLOps工具链 利用OTF构建数据仓库 构建稳固数据湖
结论
本文基于我们与企业合作构建AI/ML现代化数据湖参考架构的丰富经验，梳理了核心组件、关键构建块以及不同AI方法的权衡。这一参考架构的基础是一个建立在对象存储之上的现代化数据湖。这个对象存储系统必须能够在数百PB甚至EB级的规模上提供高性能。遵循这一参考架构，我们将能够帮助用户构建一个灵活、可扩展的数据基础设施，不仅适用于AI和ML，还能高效支持所有OLAP工作负载。
Source:Keith Pijanowski; A Reference Architecture for AI/ML Data Infrastructure; 26 March 2024
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）